A Named Data Networking Flexible Framework for 1 Management

The ongoing changes in the way we use the Internet are motivating the 8 definition of new information-distributing designs for an interworking layer. Recently, 9 information-centric networking (ICN) concepts have defined mechanisms focusing on 10 what information to get rather than where it is located. However, the still unfledged 11 architectures instantiating such concepts have disregarded vital operations, such as 12 management aspects aiming to optimize content retrieval by the User Equipment (UE). 13 In this paper, a flexible management framework is proposed, which enhances existing 14 Named Data Networking (NDN) architectures in allowing both the network and the UE 15 to employ management mechanisms over the NDN fabric. We illustrate our 16 management framework with an implementation over an open-source NDN software, 17 considering the specific case study of interface management. We quantitatively access 18 the performance gains achieved through the usage of this framework in such scenarios, 19 when compared to un-managed NDN mechanisms. 20 Index Terms – Information-Centric Networking (ICN), Named-Data Networking 21 (NDN), Network Management 22 23 1. Introduction 24 In recent years, rapid developments in how we access an ever-increasing amount of 25 new online content have changed current communication patterns. Traditional 26 communication between a pair of networked machines has evolved into a scenario 27 where new services generate unprecedented amounts of content (e.g., video traffic and 28 cloud access), and at the same time allow multi-link mobile devices to access that 29 information via different connectivity opportunities. The existing host-centric 30 architecture has been patched to encompass content-oriented mechanisms such as 31 Content Delivery Networks (CDN), peer-to-peer overlays and HTTP proxies, deployed 32 over the existing infrastructure. Supporting these enhancements to access content, 33 network operators employ a series of management procedures governing a complex 34 heterogeneous environment, through the cumulative usage of mechanisms such as 35 Quality of Service (QoS), network policies, load balancing, failback actions, over-the36 air updates, amongst others. However, the sheer amount of content being accessed has 37 highlighted functional limitations in terms of flexibility, performance and cost, 38 motivating the development of more adequate network paradigms for an Internet of the 39 Future. 40 The focus on content distribution has led to the concept of Information-Centric 41 Networking (ICN) allowing content to be addressed by name and not by location or 42 end-point addresses. This principle has motivated different approaches, such as Data43 Oriented Network Architecture (DONA) [1], Publish/Subscribe Internet Routing 1 Paradigm (PSIRP) [2], Network of Information (NetInf) [3] and Named Data 2 Networking (NDN) [4]. A survey on ICN approaches can be found in [5]. 3 These proposals leverage the evolution required by today’s Internet to support this 4 content-centric vision, focusing on aspects such as hierarchical content naming, 5 information-centric communication and content-based security, which are core features 6 of NDN [4]. However, there has been very little consideration on management aspects 7 for ICN architectures, which are fundamental for supporting network operations, such 8 as, e.g., those aiming to increase user experience when accessing content with different 9 requirements. We argue that the provision of intrinsic management functionalities is 10 important for the successful future deployment of ICNs, incrementing existing and new 11 Future Internet scenarios, with support for QoS, network policies management, amongst 12 other operations. 13 In this paper, we focus on the NDN architecture to discuss management 14 enhancements potentially addressable as well by other ICN architectures. To achieve 15 that, we define an integrated and flexible framework that: 16 1) Considers a generic approach allowing management procedures to collect input 17 or triggers from various sources, and use that information to optimize 18 network operations. These aim to assist or control network attachment 19 procedures of terminals, towards network resource optimization and user 20 experience satisfaction; 21 2) Defines interfacing points with the NDN fabric while proposing improved 22 mechanisms allowing the integration of management procedures. 23 The remainder of this document is organized as follows. Section 2 introduces the 24 base mechanisms of NDN and provides insight into current evolution. Section 3 25 presents our NDN flexible management framework, followed by Section 4 where we 26 focus on a specific use case (i.e. management of the terminal’s connection point for 27 content retrieval) and we evaluate the performance that can be achieved with our 28 framework, in this specific use case, from an experimental perspective. Lastly, Section 29 6 presents conclusions and future work. 30 2. Background and Related Work 31 2.1. NDN Basic Operation 32 NDN relies on two packet types defined in [4]: Interest and Data. Interests are used 33 by a consumer to ask for content. They contain a Content Name based on a hierarchical 34 structure: its components are separated by ‘/’, (similar to a URL, such as 35 /domain/content/Videos/videoA.mpg/version/segment), with the prefix providing global 36 and organizational routing information, and a suffix showing versioning and 37 segmentation details. When an Interest packet reaches any node with data matching the 38 Content Name, it consumes the Interest and responds with a matching Data packet, 39 carrying back the content. 40 When an NDN-node receives an Interest packet, a set of functional structures is 41 consulted: the Content Store (CS), the Pending Interest Table (PIT) and the Forwarding 42 Information Base (FIB). 43 The CS is checked to see if the requested data is already available. If the name 1 requested no entry there, the PIT is checked. This structure keeps track of Interests 2 forwarded to content sources that were not yet consumed. If an Interest has no match in 3 either the CS or PIT, a new PIT entry is created and the packet is forwarded towards 4 one or more interfaces that might lead to the respective content sources. For this, the 5 FIB associates Content Name prefixes towards potential holders of the content, with 6 some routing protocol defining the forwarding state in the FIB, (e.g., routes to 7 applications or physical interfaces), or through a registration in a local NDN store. 8 An interesting detail from [4] and [6], is the ability for FIB entries to address 9 multiple interfaces. Each NDN-node contains a Strategy Layer that can use several 10 options to forward an Interest packet. The forwarding strategy can vary from sending an 11 Interest sequentially on each face until a Data is received, to more elaborated designs 12 that evaluate which interfaces provide better performance in retrieving specific content. 13 A specific mechanism for best face determination is described in [4], where the Strategy 14 Layer runs experiments in which an Interest is sent (e.g., every second or when a packet 15 is lost) through all available faces, towards a given prefix. If a face provides lower end16 to-end delay than the previous best face, it becomes the new one until the next test. 17 Hereinafter, we refer to this process as probing. Another possibility suggested in [4] and 18 [6], is to define a program within each FIB entry that defines forwarding choices and 19 behaviour. This program could be configured with a set of instructions, such as 20 sendToAll and sendToBest, determining the forwarding of Interests under a predefined 21 and static strategy. However, this behaviour is not thoroughly explored in [4] and [6], 22 which provides a default strategy of sending Interests to all broadcast capable faces and, 23 if no answer is received, all other faces are tried out in sequence. 24 2.2. NDN Evolution 25 There have been several proposals enhancing the base architecture of NDN not only 26 to better tackle the problems it proposes to address, but also to improve its behaviour 27 when handling current or future traffic patterns. 28 The work in [7] evaluates the performance of NDN when mapped to a Voice over IP 29 (VoIP) application, transporting SIP and RTP data in a real-time conversation. 30 Extensions supporting NDN-node mobility, without having to undergo a full 31 Interest re-routing toward the content source, have been proposed [8]. This work 32 considers a proxy acting as an anchor point for Interest and Data packets. When nodes 33 connect to an NDN-domain, they associate with that proxy (using it to reach content on 34 their behalf) and when they move, they report movement changes to it, updating the 35 Data packets being forwarded to the new location. However, this update does not 36 provide any preferences, policies or any other information which could be used for 37 assisting and managing this mobility procedure, thus allowing only un-optimized 38 handovers. 39 The authors of [9] analyse how Interest route selection is affected by policies, 40 exploring content name granularity. However, it focuses on the economic incentives for 41 routing only, not considering aspects such as different content requirements, 42 1 In fact, under NDN, the term interface is replaced by face (which we will use from now on) because packets are not only forwarded over hardware interfaces but also directly between application processes. content/application-driven policies or dynamic route selection based on different 1 interface technologies. 2 2.3. Management Requirements in NDN 3 A thorough analysis of deployment motivations for NDN as a future 4 internetworking architecture is presented in [10], highlighting the need for network5 grade solutions, such as manageability aspects that allow the network to control the 6 content reception by the user (i.e., optimal link selection, Quality of Service, policing, 7 etc.). In fact, considering the outline of the NDN project [6], management procedures 8 are only considered for Storage and Usable Trust. These, along with the previously 9 mentioned Strategy Layer, do not consider network input or intervention in their 10 management processes. As such, they are limited to operation based on static rules, or 11 relying on information collected locally by the node. Its management, as it is, is 12 completely local. As a result, there is no coordinated effort between NDN-nodes and the 13 network as a whole, with which to provision or optimize not only NDN operating 14 aspects, but also the performance of Data packet reception in terms of policies. The 15 usage of policies, analogous to the IP world, allows the network to control and suggest 16 to NDN-nodes the most preferable access network, by providing discovery information 17 (e.g., which WLAN networks are available within a 3G cell) or by indicating a set of 18 rules considering preferred access points at different times of the day, or routing traffic 19 flows depending on the content. 20 3. The NDN Flexible Management Framework 21 22 3.1 General Architecture 23 This section describes the management framework proposed in this paper for NDN. 24 We argue that the interaction between information existing in the network and 25 information within the point-of-view of the terminal could be used to impact NDN 26 operations, optimizing both network procedures and user experience. This framework 27 was designed as a comprehensive and flexible solution, capable of supporting the 28 functionalities that may be required by different management procedures in a future 29 content-oriented network, such as QoS provision and face management. 30 Figure 1 shows a general overview of the different functional entities comprising 31 our framework. It considers the deployment of a Manager Entity (ME) in the network, 32 able to interact with a set of Management Agents (MA) located in different devices, 33 such as network and user equipment. For simplicity, in the remaining of this paper we 34 focus on MAs deployed in User Equipment (UE). As a result of the interaction between 35 MEs and MAs, the network and any UE can exchange information to appropriately 36 coordinate procedures, taking advantage of the different information available in the 37 network and locally at the UE. By deploying the different management entities as 38 application processes, the framework can be easily decoupled from the underlying 39 network architecture, enabling easy interoperation with any Information-Centric 40 network approach. 41 2 The example policy characteristics highlighted here are based on the Discovery and Inter-Routing policies as defined by the 3GPP in the 3GPP TS 24.312 technical specification (Release 10). Considering this traditional network management approach, the challenge is centred 1 on how the MA and ME entities interface with the NDN fabric. Figure 1a presents the 2 core components of the NDN architecture at the UE, also coupling an MA. This 3 functional entity can be deployed as a single application process that interfaces with 4 internal NDN structures, such as the PIT and the FIB. Thus, the MA is able to access 5 and update these structures as a result of any management procedures. The UE can run 6 end-user applications, such as web browsing, telephony or Internet TV, which are able 7 to exchange Interest and Data packets. Our framework also regards management (e.g., 8 event generation and sending/receiving commands to optimize a NDN-related process) 9 as content exchanged through Interest and Data packets. MAs residing inside NDN10 enabled UEs behave as producers and consumers of content related to management 11 operations, and any management information provided by the ME is viewed as an NDN 12 name (e.g., under the name prefix /domain/management/ME/). Moreover, the MA can 13 also interface with local applications to obtain information about the content to be 14 retrieved. This provides relevant information that may be used to guide the decisions of 15 the management processes. As an example, a local application can provide the MA with 16 information about QoS requirements for a specific video content. This information can 17 be provided to the ME, which can coordinate an appropriate resource delivery in the 18 network. Finally, the MA is capable of interfacing with the lower layers of the UE, 19 obtaining link information that can also be relevant to the management procedures (e.g., 20 identifying available wireless access networks in the vicinity of the UE). 21 Shown in Figure 1b, the ME is a functional entity located in the operator network 22 that interacts with MAs to handle management procedures. The ME is triggered by 23 different mechanisms, existing elsewhere in the network, to report information that can 24 be relevant to aid management. The ME processes this information, which can then be 25 used to coordinate any necessary management operations. For example, the ME can be 26 notified when the traffic load of a given access network exceeds predefined thresholds. 27 Information about traffic load can then be used by the ME to coordinate an appropriate 28 selection of faces in the UE for content retrieval. This logical entity can be implemented 29 in a single centralized network node, or distributed over nodes residing in different parts 30 of the network, for the sake of scalability and redundancy. The flexibility of the 31 proposed NDN management mechanism can be reutilized in different ways to support 32 distributed coordination, allowing the exchange of state amongst different MEs 33 belonging to different domains, or by using other distributed network mechanisms to act 34 as triggers for NDN management operations. Such interfacing can go beyond triggering 35 and can take many forms (e.g., SNMP), but is out of scope of this paper. 36 The flexibility of this model allows its application to a wide range of management 37 scenarios. As an example, in QoS provisioning, the MA could be used to dynamically 38 provide user and application requirements to the ME in the network. This information 39 can be used to initiate the necessary admission control and resource reservation 40 procedures in the network, using NDN interfaces located in the required entities. On the 41 other hand, in the case of face management, a change in access network traffic 42 conditions can trigger a management procedure in the ME. Here, the ME can provide 43 new traffic policies to the MA of the UE, describing other usable access networks. As a 44 result, internal NDN structures such as the FIB can be updated at the UE to enforce 45 network management decisions. All management traffic will look like regular NDN 46 traffic to the NDN-nodes, identified by specific names. 47 3.2 Support Procedures 48 The framework presented in Section 3.1 requires the exchange of management data 1 between the MA and an ME. This exchange must fulfil the following properties: 2 • Security. MA and ME must be able to authenticate and determine the trust that 3 can be established on management data. Also, a UE can use a broadcast 4 interface towards a Point of Attachment (PoA), and it is necessary to protect the 5 confidentiality, integrity and authenticity of the content exchanged, as it may 6 contain sensible information that must not be vulnerable to unauthorized 7 eavesdropping, modification or creation. 8 • Asynchronous exchange. Other than just pulling content via an Interest/Data 9 packet exchange, both the MA and the ME must be able to push unsolicited 10 management content to one another. 11 • Reliability (optional). NDN transport can operate on top of unreliable data 12 delivery services. Nevertheless, in some use cases, content exchanges between 13 the MA and the ME must proceed reliably (e.g., to send the ME a set of QoS 14 requirements that should be satisfied to retrieve a specific video content). 15 3.2.1 Bootstrapping for Reliable and Secure Management Content Exchange 16 Inspired by the procedures used to setup a secure Voice-over-NDN conversation [7], 17 we have defined a bootstrapping procedure between the MA and the ME, illustrated in 18 Figure 2. 19 The first step involves the MA discovering an appropriate ME, by broadcasting an 20 Interest with the name /domain/management/mgmt-case/ME to its local network. The 21 name component mgmt-case refers to the management capacities that the MA requires 22 from the ME (e.g. an ME to handle QoS provisioning can be discovered by issuing an 23 Interest to /domain/management/qos/ME). As a result, the UE obtains a short hand 24 identifier for the ME (i.e. the ME-publisher-id) and a key locator, which indicates the 25 name that can be used to retrieve the public key of the ME. Assuming that the public 26 key of the ME is authorized by another key trusted by the MA, (e.g. a public key 27 corresponding to /domain), the MA can identify the ME as an acceptable signer for 28 management data. The MA selects an encryption algorithm, out of those indicated by 29 the ME in the Data packet, and generates a session key, Ks. Then, it registers its desire 30 to serve Interests matching a given NDN name (e.g. /domain/management/mgmt31 case/MA-publisher-id), where MA-publisher-id is a global and unique identifier for the 32 MA, such as the cryptographic digest of its public key). Finally, the MA sends a new 33 Interest to retrieve management Data from the ME that includes, as NDN name 34 components, the shorthand identifier of the MA (MA-publisher-id) and some additional 35 information encrypted with the public key of the ME, such as the encryption algorithm 36 (security-mechanism) and Ks chosen to guarantee confidentially of the content 37 exchanged between the MA and the ME. Note that different security infrastructures 38 could be used in this approach, suitably adapted. With this, the MA is prepared to 39 securely receive content from the ME. 40 Nevertheless, before the ME starts exchanging management content with the MA, it 41 generates a challenge (i.e. a nonce) and expresses the Interest in obtaining the response 42 to this challenge from the MA. The MA responds to the Interest with a Data packet 43 containing the answer to the challenge. Consequently, the ME can retrieve the public 44 key of the MA and identify it as an acceptable signer for management content. In 45 addition, the ME verifies the signature of the Data packet and checks the validity of the 1 answer to the challenge. Therefore, this exchange allows the ME to verify that the 2 encryption algorithm and the session key are valid for the MA. At this point, the ME is 3 prepared to receive management data from the MA. 4 Once these initialization procedures conclude, MA and ME can exchange 5 information to coordinate the execution of any management activities. 6 3.2.2 Asynchronous Exchange of Management Data 7 After bootstrapping, the framework allows the MA to securely pull management 8 content from the ME and vice versa. Case 1 in Figure 2 shows the scenario where the 9 MA retrieves a specific management information item content-name from the ME (the 10 procedure of having the ME pulling content from the MA would proceed in a similar 11 way). 12 In addition, pushing unsolicited content (e.g., commands to nodes, or informational 13 events to the network) between the MA and the ME is also supported. As suggested in 14 [6], we support pushing content between applications by implementing a double 15 Interest/Data exchange. Case 2 of Figure 2 shows the necessary procedures allowing 16 the MA at the UE to push management data towards the ME. The procedure to push 17 content from the ME to the MA follows a similar approach. 18 This procedure starts with the MA sending an Interest to the ME soliciting it to receive 19 management content with a local sequence number. Sequencing is necessary to enable 20 the recovery of new content instead of cached content. If the ME is interested in 21 retrieving content from the MA, it answers back with a Data packet, indicating its 22 willingness to accept management content. Then, the ME sends an Interest to retrieve 23 the management data with the sequence number given by the MA. The MA responds 24 with a Data packet containing the information it wanted to push to the ME. The 25 information contained in the Data packet is encrypted with the session key established 26 during bootstrapping. 27 Finally, if reliability is desired, MAs and MEs must retransmit Interest packets not 28 satisfied in a reasonable period of time (either to pull or push management content). 29 This mechanism is suggested in [4] and [6], and improves the reliability of the 30 asynchronous data exchange. 31